System and method for providing warranties in electronic commerce

ABSTRACT

A system and method are disclosed for providing warranties that financially guarantee one or more facts associated with an electronic transaction. In a preferred embodiment, warranties issued in the present system comprise a contract between a first party and a second party in which the first party: (1) warrants one or more warranted facts (2) for damages up to a warranted amount (3) if claimed by a relying customer within a claim period. The warranty is preferably issued by a participant in response to a request received from a customer that specifies a desired warranted amount and claim period. The participant and root entity evaluate the request in light of a plurality of factors and determine whether or not the warranty should be issued. In a preferred embodiment, the warranty comprises a contract between the buyer and its issuing participant. The seller is preferably a third-party beneficiary of this contract.

[0001] This application is a continuation of U.S. patent applicationSer. No. 09/928,998, filed Aug. 14, 2001, entitled System and Method forProviding Warranties in Electronic Commerce, which claimed priority fromU.S. provisional patent application serial No. 60/224,994, filed Aug.14, 2000, entitled Signing Interface Compliance Requirements, Smart CardCompliance Requirements, Warranty Service Functional Requirements, andAdditional Disclosure; and U.S. provisional patent application serialNo. 60/259,796, filed Jan. 4, 2001, entitled Warranty ManagerApplication Programming Interface, Warranty Messaging Specification, andWarranty Manager Functional Requirements, all three of which are herebyincorporated by reference.

COPYRIGHT NOTICE

[0002] A portion of the disclosure of this patent document containsmaterial which is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument or the patent disclosure, as it appears in the Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

BACKGROUND OF THE INVENTION

[0003] The world of electronic commerce has created new challenges toestablishing relationships between contracting parties. One of thosechallenges springs from the fact that the parties to the transactioncannot see or hear each other, and cannot otherwise easily confirm eachother's identity and authority to act.

[0004] One remedy for this problem is to provide each contracting partywith a private key for signing transmitted messages. The signing partymakes available an associated public key that decrypts messages signedwith the party's private key, and thus enables a receiving party toconfirm the identity of the sender.

[0005] But the sender's public key may not be known a priori to therecipient. In that event, the sender may transmit with its signedmessage a digital certificate issued by a certification authority. Thecertificate is itself a signed electronic document (signed with theprivate key of the certification authority) certifying that a particularpublic key is the public key of the sender.

[0006] In some cases, the recipient may be unfamiliar with the publickey of the certification authority or may not know whether thecertificate is still valid. In that event, the recipient may wish tocheck the validity of the certificate with an entity that it trusts. Inaddition, the recipient may wish to obtain a financial guarantee toprotect itself against damage that it may suffer from reliance on aninvalid certificate.

SUMMARY OF THE INVENTION

[0007] A system and method are disclosed for providing warranties thatfinancially guarantee one or more facts associated with a an electronictransaction. In a preferred embodiment, the warranties are providedwithin the context of a four-corner trust model. The four-corner modelcomprises a buyer, also referred to as the subscribing customer, and aseller, also referred to as the relying customer, who engage in anon-line transaction.

[0008] In a preferred embodiment, the buyer is a customer of a firstfinancial institution, referred to as an issuing participant. Theissuing participant acts as a certification authority for the buyer andissues the buyer a hardware token including a private key and a digitalcertificate signed by the issuing participant.

[0009] In a preferred embodiment, the seller is a customer of a secondfinancial institution, referred to as the relying participant. Therelying participant acts as a certification authority for the seller andissues the seller a hardware token including a private key and a digitalcertificate signed by the relying participant. The system also includesa root entity that maintains a root certification authority that issuesdigital certificates to the issuing and relying participants.

[0010] In a preferred embodiment, a warranty issued in the presentsystem comprises a contract between a first party and a second party inwhich the first party: (1) warrants one or more warranted facts (2) fordamages up to a warranted amount (3) if claimed by a relying customerwithin a claim period. The warranty is preferably issued by aparticipant in response to a request received from a customer thatspecifies a desired warranted amount and claim period. The participantand root entity evaluate the request in light of a plurality of factorsand determine whether or not the warranty should be issued. In apreferred embodiment, the warranty comprises a contract between thebuyer and its issuing participant. The seller is preferably athird-party beneficiary of this contract.

[0011] In a preferred embodiment, in order to manage the liability risksassociated with issuing warranties, the root entity imposes a series oflimits, called participant warranty caps, on the warranty volume thateach issuing participant may have outstanding. These caps are intendedto limit the aggregate level of operating risk exposure for individualparticipants and to limit the overall risk in the system.

[0012] If a seller suffers damage as a result of its reliance on awarranted fact, the seller may file a claim for compensation against theissuing participant. If the issuing participant determines to pay theclaim, it transfers sufficient funds to the relying participant for thebenefit of the seller. If the issuing participant determines to disputethe claim, the issuing participant and seller proceed to disputeresolution.

[0013] In a preferred embodiment, the root entity imposes collateralrequirements on the issuing participant that may be used to pay claimsfor damages filed by sellers if the issuing participant is unable orunwilling to satisfy a warranty claim. The collateral is preferably heldby a third-party collateral agent that is contractually obligated to paywarranty claims from the issuing participant's collateral account ifordered to do so under system operating rules.

[0014] The features and advantages described in the specification arenot all inclusive, and many additional features and advantages will beapparent to one of ordinary skill in the art in view of the drawings,specification, and claims hereof.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above summary of the invention will be better understood whentaken in conjunction with the following detailed description andaccompanying drawings, in which:

[0016]FIG. 1 is a block diagram of a preferred embodiment of afour-corner model suitable for use in the present system;

[0017]FIG. 2 is a block diagram of a preferred embodiment showingcomponents provided at entities in the four-corner model;

[0018]FIG. 3 illustrates a preferred embodiment of a warranty-issuanceprocess flow;

[0019]FIG. 4 illustrates a preferred embodiment of certain messages usedin the preferred embodiment of FIG. 3;

[0020]FIG. 5 illustrates a preferred embodiment of certain messages usedin the preferred embodiment of FIG. 3;

[0021]FIG. 6 illustrates a preferred embodiment of certain messages usedin the preferred embodiment of FIG. 3;

[0022]FIG. 7 illustrates a preferred embodiment of a warranty-claimprocess flow;

[0023]FIG. 8 illustrates a preferred embodiment of certain messages usedin the preferred embodiment of FIG. 7;

[0024]FIG. 9 illustrates a preferred embodiment of a process forcollateral updating and monitoring;

[0025]FIG. 10 illustrates a preferred embodiment for implementing awarranty manager;

[0026]FIG. 11 illustrates an alternative preferred embodiment forimplementing a warranty manager;

[0027]FIG. 12 illustrates a preferred embodiment of data elements usedto construct warranty messages;

[0028]FIG. 13 illustrates a preferred embodiment of data descriptionsand restrictions for the data elements in FIG. 12;

[0029]FIG. 14 illustrates a preferred embodiment of data elements usedto construct warranty claims messages; and

[0030]FIG. 15 illustrates a preferred embodiment of data elements, andcorresponding descriptions and restrictions, used to constructvalidation reporting messages.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] The present disclosure relates to a system and method forproviding warranties that financially guarantee one or more factsassociated with an electronic transaction. In a preferred embodiment,warranties are provided within the context of a four-corner trust model.A preferred embodiment of the four-corner model is shown in FIG. 1.

[0032] As shown in FIG. 1, the four-corner model preferably comprises afirst institution 102 and a second institution 104. First institution102 is referred to as the “issuing participant” because it is aparticipant in the present system and issues to its customers tokensthat include a private key and a digital certificate signed by theissuing participant, as described below. Second institution 104 isreferred to as the “relying participant” because it is a participant inthe present system and its customers rely on representations made byissuing participant 102 and issuing participant 102's customers, asdescribed below. Participants 102, 104 may preferably be banks or otherfinancial institutions.

[0033] Also shown in FIG. 1 are a first customer 106 and a secondcustomer 108. First customer 106 and second customer 108 are preferablycustomers of issuing participant 102 and relying participant 104,respectively. First customer 106 is referred to as the “subscribingcustomer” because this customer subscribes to services provided byissuing participant 102. First customer 106 is also referred to as the“buyer” because it typically fills that role in transactions with secondcustomer 108, as described below.

[0034] Second customer 108 is referred to as the “relying customer”because it relies on representations made by both issuing participant102 and subscribing customer 106. Second customer 108 is also referredto as the “seller” because it typically fills that role in transactionswith subscribing customer 106, as described below. It should berecognized, however, that although the description below speaksprimarily in terms of a buyer 106 and a seller 108, first customer 106and second customer 108 may instead have different roles in a giventransaction. For example, first customer 106 may be a borrower repayinga loan to second customer 108.

[0035] Also shown in FIG. 1 is a root entity 110. Root entity 110 ispreferably an organization that establishes and enforces a common set ofoperating rules for facilitating electronic commerce and electroniccommunications. Root entity 110 may be owned jointly by a plurality ofbanks and/or other financial institutions that have agreed to adhere tothese operating rules. One exemplary embodiment of such a root entity isdescribed in copending U.S. application Ser. No. 09/502,450, filed Feb.11, 2000, entitled System and Method for Providing Certification Relatedand Other Services and in copending U.S. application Ser. No.09/657,623, filed Sep. 8, 2000, entitled System and Method for ProvidingCertificate-Related and Other Services, which are hereby incorporated byreference.

[0036]FIG. 2 illustrates components provided at each entity in apreferred embodiment of the present system. As shown in FIG. 2,participants 102, 104, and root entity 110 are each preferably providedwith a transaction coordinator 202 that serves as a gateway fortransmitting and receiving all inter-entity messages related to servicesprovided by the present system. Transaction coordinators 202 provide asingle interface to issuing participant 102's and relying participant104's on-line services and implement safeguards necessary to ensuresecure electronic communications between transaction coordinators 202and other entities in the four-corner model, as described in copendingU.S. patent application Ser. No. 09/657,605, filed on Sep. 8, 2000,entitled System and Method for Providing Certificate Validation andOther Services, which is hereby incorporated by reference. Eachtransaction coordinator 202 is preferably provided with an associatedhardware security module (HSM) 218 for signing and verifying messages.Participants 102, 104, and root entity 110 are each further preferablyprovided with an Online Certificate Status Protocol (OCSP) responder 204and associated HSM 206 for signing and verifying signatures on messages.

[0037] Participants 102, 104, and root entity 110 are each furtherpreferably provided with a warranty manager 230. Warranty manager 230 isadapted to receive and transmit messages relating to warranty servicesand evaluate warranty requests, as described in more detail below.

[0038] As further shown in FIG. 2, relying customer 108 is preferablyprovided with a Web server 220 adapted to receive and transmitinformation via the Internet and a bank interface 222 for accessingsystem services. An exemplary bank interface is described in copendingU.S. application Ser. No. 09/657,604, filed on Sep. 8, 2000, entitledSystem and Method for Facilitating Access by Sellers toCertificate-Related and Other Services, which is hereby incorporated byreference. Relying customer 108 is preferably further provided with anHSM 250 for signing and verifying signatures on messages.

[0039] As further shown in FIG. 2, subscribing customer 106 ispreferably provided with a Web browser 224 adapted to receive andtransmit information via the Internet. Subscribing customer 106 is alsopreferably provided with a smartcard subsystem 226 adapted to signelectronic messages. In a preferred embodiment, smartcard subsystem 226may include a smartcard reader, a smartcard driver, a smartcard token,and other software, as described in U.S. provisional application serialNo. 60/224,994, filed Aug. 14, 2000, entitled Signing InterfaceRequirements, Smart Card Compliance Requirements, Warranty ServiceFunctional Requirements, and Additional Disclosure and U.S. applicationSer. No. ______, filed Aug. 14, 2001, entitled System and Method forSecure Smartcard Issuance, which are hereby incorporated by reference.In a preferred embodiment, the smartcard token is issued to subscribingcustomer 106 by its issuing participant 102.

[0040] Subscribing customer 106 is also preferably provided with asigning interface 225. Signing interface 225 is adapted to invokesmartcard 226 to execute a digital signature, as described in U.S.provisional application serial No. 60/224,994, filed Aug. 14, 2000,entitled Signing Interface Requirements, Smart Card ComplianceRequirements, Warranty Service Functional Requirements, and AdditionalDisclosure and U.S. application Ser. No. ______, filed Aug. 14, 2001,entitled System and Method for Facilitating Signing by Buyers inElectronic Commerce, which are hereby incorporated by reference.

[0041] In a preferred embodiment, each system entity is furtherpreferably provided with two digital certificates (and correspondingprivate keys) to facilitate authentication: an identity certificate anda utility certificate.

[0042] The identity private key is used to produce digital signaturesthat are required by root entity 110 as evidence of an entity'scontractual commitment to the contents of an electronic transaction,such as a purchase order.

[0043] The utility private key is used to provide additionaltransactional security. Typically, utility certificates are used tosupport secure socket layers (SSL), to sign secure multipurpose internetmail extension (S/MIME) messages, and for other utility applications.Any reference in this document to the term “certificate” refers to anidentity certificate unless otherwise stated.

[0044] In a preferred embodiment, root entity 110, in its capacity as acertification authority, uses a root private key to create the digitalcertificates of each system participant (e.g., issuing participant 102and relying participant 104). In addition, it uses the root private keyto create digital certificates for each system component maintained byroot entity 110 that has digital signing capability, including OCSPresponder 204 _(R) and transaction coordinator 202 _(R).

[0045] In addition, each system participant (e.g., issuing participant102 and relying participant 104), in its capacity as a certificationauthority, uses the private key associated with its certificate fromroot entity 110 to create the digital certificates of its customers(e.g., subscribing customer 106 and relying customer 108). In addition,it uses this private key to create digital certificates for each systemcomponent that it maintains that has digital signing capability,including its OCSP responder 204 and transaction coordinator 202. In analternative embodiment, the digital certificates for system componentswith digital signing capability that are maintained by a participant maybe issued by root entity 110.

[0046] It should also be recognized that each customer 106, 108, may bea business entity, such as a corporation, that employs many individuals.In such cases, customers 106, 108 preferably authorize some or all ofthese individual employees to transact and utilize system services ontheir behalf. Issuing participant 102 preferably issues a separatesmartcard token having a distinct private key and associated digitalcertificate to each authorized employee of subscribing customer 106.Similarly, relying participant 104 (in its capacity as “issuingparticipant” to relying customer 108) preferably issues a separatesmartcard token having a distinct private key and associated digitalcertificate to each authorized employee of relying customer 108. Thedigital certificates preferably include the individual employee's nameand identify the customer for whom he or she works. In an alternativeembodiment, the private key may instead be included in a software tokenprovided to the individual.

[0047] Although the preferred embodiment described above employstransaction coordinators at each participant 102, 104 and at root entity110, it should be noted that, in an alternative embodiment, the systemmay be designed without some or all of these transaction coordinators.In this alternative embodiment, messages created, signed, or transmittedby, to, or via a transaction coordinator in the following description,may instead be created, signed, or transmitted by, to, or via asubstitute system component adapted to comprise appropriate hardwareand/or software to provide the desired functionality.

Warranty Products

[0048] Before describing in detail preferred embodiments for requestingand issuing warranties, an overview of the preferred warranty productsprovided by the present system is presented. In a preferred embodiment,a warranty issued in the present system comprises a contract between afirst party and a second party in which the first party: (1) warrantsone or more warranted facts (2) for damages up to a warranted amount (3)if claimed by a relying customer within a claim period.

[0049] In a preferred embodiment, the warranted facts include: (a) thata subscribing customer 106 will not repudiate a digital signatureexecuted with an identity private key issued by its issuing participant102; and (b) that the subscribing customer 106's certificate was validat the time the signature was executed.

[0050] In a preferred embodiment, to repudiate a digital signature inthis context means to deny that a signature is genuine. A signature isgenuine in this context if it is a signature of the subscribing customeron a digital transmission made in a representative capacity by theindividual named in the digital certificate associated with the privatekey used to sign the transmission.

[0051] In an alternative preferred embodiment, to repudiate a digitalsignature in this context means to deny that a signature is authorized.A signature is authorized in this context if, with respect to a digitaltransmission, the individual who made the digital signature of thesubscribing customer on a digital transmission had actual authority todo so. Authorized in this context does not mean that the issuance orsigning of the digital transmission or the execution or performance ofany underlying transaction was or is rightful or proper.

[0052] The warranted amount establishes the maximum dollar amount ofrecovery that a relying customer 108 may recover for damage suffered asa result of reliance on the warranty. As noted, this amount ispreferably a maximum, i.e., the highest amount that relying customer 108may recover. If the relying customer's damage is less than this maximum,then the relying customer preferably recovers only its actual damage.

[0053] The claim period is the period during which relying customer 108must file a claim under the warranty in order to recover for any damagesuffered. If no claim is filed within the claim period, the warrantyexpires, as described in more detail below.

[0054] In a preferred embodiment, warranties expire at 22:00 GMTregardless of the time of day the warranty issued. For example, for awarranty issued with a claim period of 14 days, 14 24-hour periods arecounted from the time the warranty is issued, and the warranty expiresat 22:00 GMT following that time. Thus, in this preferred embodiment,if, for example, a warranty is issued on the first of the month at 2:00PM Eastern Daylight Time, the warranty would expire at 22:00 GMT (i.e.,6:00 PM Eastern Daylight Time) on the 15^(th) of the month. By contrast,in this preferred embodiment, if, for example, a warranty is issued onthe first of the month at 7:00 PM Eastern Daylight Time, the warrantywould expire at 22:00 GMT on the 16^(th) of the month.

[0055] In an alternative embodiment, warranties may expire at 21:00 GMTon the last day of the claim period regardless of the time of day thewarranty issued, as described in U.S. provisional patent applicationserial No. 60/224,994, filed Aug. 14, 2000, entitled Signing InterfaceCompliance Requirements, Smart Card Compliance Requirements, WarrantyService Functional Requirements, and Additional Disclosure, which ishereby incorporated by reference.

[0056] In a preferred embodiment, warranties are issued by a participantin response to a request received from a customer. The requestpreferably specifies the desired warranty amount and claim period. Theparticipant and root entity 110 evaluate the request in light of aplurality of factors, described in more detail below, and determinewhether or not the warranty should be issued. In a preferred embodiment,the warranty is requested by a subscribing customer 106 from its issuingparticipant 102. In a preferred embodiment, the first party to thewarranty contract is issuing participant 102 and the second party to thewarranty contract is subscribing customer 106. Relying customer 108 ispreferably a third-party beneficiary of the warranty contract withrecourse against issuing participant 102 for monetary compensation up tothe warranted amount.

[0057] In a preferred embodiment, the operating rules establish a $500minimum value for a warranty. In addition, issuing participant 102 mayestablish its own minimum value for warranties that it issues which maynot be lower than that established by root entity 110. The systemoperating rules also preferably establish a $100,000 maximum value for awarranty. In addition, issuing participant 102 may establish its ownmaximum value for warranties that it issues which may not be higher thanthat established by root entity 110. In a preferred embodiment, theoperating rules require that the claim period of a warranty be one of:7, 14, 30, 60, 90, or 180 days.

Warranty Caps

[0058] In a preferred embodiment, in order to manage the liability risksassociated with issuing warranties, root entity 110 imposes a series oflimits, called participant warranty caps, on the warranty volume thateach issuing participant may have outstanding. These caps are intendedto limit the aggregate level of operating risk exposure for individualparticipants and to limit the overall risk in the system.

[0059] As used herein, the term “warranty volume” refers to theaggregate dollar amount of outstanding (i.e., unexpired) warrantiesissued by or for a system entity. Thus, for example, if an issuingparticipant has issued 500 warranties with warranted amounts of $500each and 200 warranties with warranted amounts of $10,000 each, then theparticipant's warranty volume is $2.25 M. In addition, as used herein,the term “warranty cap utilization,” when expressed as an amount ofcurrency, refers to the warranty volume of an issuing participant 102.When expressed as a percentage value, the term “warranty caputilization” refers to the participant's warranty volume divided by itswarranty cap.

[0060] As described below, in a preferred embodiment, a participant'swarranty volume is compared to its participant warranty cap before awarranty is issued and the warranty is not issued if the warrantedamount would push the issuing participant over its cap.

[0061] A preferred embodiment for calculating a participant warranty capfor each issuing participant 102 is described below. Any reference inthis document to a “warranty cap” refers to a participant warranty cap,unless otherwise specified.

[0062] In a preferred embodiment, each issuing participant 102 may alsoestablish a customer warranty cap for each of its subscribing customers106. A customer warranty cap limits the total warranty volume issued fora subscribing customer 106 that may be outstanding at any time, asdescribed in more detail below.

[0063] In a preferred embodiment, each issuing participant 102 may alsoestablish an individual warranty cap for each employee of subscribingcustomer 106 that is authorized to act on the customer's behalf. Anindividual warranty cap limits the total warranty volume issued for anauthorized individual that may be outstanding at any time, as describedin more detail below.

[0064] In a preferred embodiment, root entity 110 may also establish acountry-specific warranty cap. This warranty cap limits the warrantyvolume that all participants in a given country may have outstanding atany time.

[0065] In a preferred embodiment, subscribing customer 106 may alsoestablish warranty caps for itself and its employees that limit thewarranty volume that it or its employees may have outstanding at anytime. Subscribing customer 106 conveys these warranty caps to itsissuing participant which enforces them in its warranty-issuanceprocess, as described in more detail below.

Collateral

[0066] In a preferred embodiment, root entity 110 imposes collateralrequirements on issuing participant 102 that may be used to pay claimsfor damages filed by relying customers if the issuing participant isunable or unwilling to satisfy a warranty claim. The collateral ispreferably held by a third-party collateral agent that is contractuallyobligated to pay warranty claims from a participant's collateral accountif, pursuant to dispute resolution procedures described in more detailbelow, the participant is ordered to pay a warranty claim but is unableor unwilling to do so. A preferred embodiment for calculating collateralrequirements for each issuing participant 102 is described in moredetail below.

Warranty-Issuance Process Flow

[0067] A preferred embodiment of a warranty-issuance process flow is nowdescribed in connection with FIG. 3 and FIGS. 4-6. As will be recognizedfrom the description below, FIGS. 4-6 respectively cover distinctcontingencies that may occur during operation of this preferredembodiment. In particular, FIG. 4 is directed to the case where awarranty is issued; FIG. 5 is directed to the case where a warranty isrejected by issuing participant 102; and FIG. 6 is directed to the casewhere a warranty is rejected by root entity 110.

[0068] Before commencing the description of this preferred embodiment, abrief overview of the messages shown in FIGS. 4-6 is presented.Preferred specifications for each of these messages are described inmore detail below. As shown in FIGS. 4-6, the system utilizes thefollowing messages in the warranty-issuance process:

[0069] (1) Wrequest: used by a customer to request a warranty;

[0070] (2) Wproposed: used by issuing participant 102 to propose awarranty to root entity 110;

[0071] (3) Wconfirmation: used by root entity 110 to indicate approvalof the terms of a proposed warranty;

[0072] (4) Wauthorizedandissued: used by issuing participant 102 toindicate approval of a requested warranty and to confirm warrantyissuance; and

[0073] (5) WReject: used by issuing participant 102 and root entity 110to indicate rejection of a warranty request.

[0074] Turning to FIG. 3, in step 301, subscribing customer 106 visitsrelying customer 108's Web site. The parties preferably authenticatethemselves to each other over an SSL session with their utility keys.

[0075] In step 302, Web server 220 communicates data to be digitallysigned to browser 224 (e.g., a purchase order for an agreed-totransaction). In step 303, the data to be signed is forwarded tosmartcard subsystem 226 which signs the data. In step 304, the executeddigital signature is returned to browser 224. In a preferred embodiment,this signing process may be facilitated by using a signing interface 225to invoke smartcard subsystem 226, as described in U.S. provisionalapplication serial No. 60/224,994, filed Aug. 14, 2000, entitled SigningInterface Requirements, Smart Card Compliance Requirements, WarrantyService Functional Requirements, and Additional Disclosure, which ishereby incorporated by reference.

[0076] In step 305, software on the subscribing customer's computercreates a request for warranty and transmits the request to transactioncoordinator 202 _(IP) of issuing participant 102 (message 1 in FIGS.4-6). In a preferred embodiment, this software may be implemented as acomponent of the signing interface. In an alternative embodiment, thissoftware may be implemented as a component of smartcard subsystem 226.In yet another alternative embodiment, this software may be implementedas a plug-in to browser 224 or as a component of another suitablesoftware program resident on the subscribing customer's computer. Thewarranty request is preferably digitally signed by subscribing customer106.

[0077] Upon receipt of the request for warranty, in step 306,transaction coordinator 202 _(IP) checks that the subscribing customer'sdigital certificate is valid. In a preferred embodiment, this step maybe performed by validating the digital certificate with OCSP responder204 _(IP). If the digital certificate is not valid, processing proceedsto step 312, described below.

[0078] If the subscribing customer certificate is valid, then, in step307, transaction coordinator 202 _(IP) forwards the request to itswarranty manager 230 _(IP) for a determination as to whether issuingparticipant 102 may and/or should assume the liability associated withthe warranty requested by subscribing customer 106 (message 2 in FIGS.4-6).

[0079] Warranty manager 230 _(IP) receives the warranty request messagefrom transaction coordinator 202 _(IP) and evaluates the warrantyrequest both with respect to its internal risk management policies andwith respect to the total value of warranties it has already extended.In particular, in step 308, warranty manager 230 _(IP) checks that thewarranty request is for a permitted amount (i.e., not greater than anymaximum specified by issuing participant 102 or root entity 110 and notless than any minimum specified by issuing participant 102 or rootentity 110). If the request is not for a permitted amount, processingproceeds to step 312, described below. In step 309, warranty manager 230_(IP) checks that the warranty request is for a permitted claim period(i.e., is for one of 7, 14, 30, 60, 90, or 180 days, in the preferredembodiment described above). If the request is not for a permitted claimperiod, processing proceeds to step 312, described below.

[0080] In step 310, warranty manager 230 _(IP) checks that the requestedwarranty amount will not cause any established warranty cap to beexceeded. Thus, warranty manager 230 _(IP) retrieves from memory thewarranty cap utilization of issuing participant 102 and checks that therequested warranty amount will not cause its own participant warrantycap to be exceeded, as well as any other warranty caps (e.g., customeror individual warranty caps) established by itself or by subscribingcustomer 106. If the requested warranty would cause any established capto be exceeded, then processing proceeds to step 312, described below.

[0081] In step 311, warranty manager 230 _(IP) performs any other checksor risk management analysis put in place by issuing participant 102. Forexample, issuing participant 102 may implement fraud software thatdetects unlikely usage patterns for a digital certificate and denies awarranty when such a usage pattern is detected. If any such additionalcheck fails or if any such analysis indicates that no warranty should beissued, processing proceeds to step 312, described below.

[0082] If one or more of the above checks fail or if any other riskmanagement process indicates that a warranty should not be issued, then,in step 312, warranty manager 230 _(IP) denies the requested warranty bytransmitting a rejection message to transaction coordinator 202 _(IP)(message 3.2 in FIG. 5). In step 313, transaction coordinator 202 _(IP)digitally signs the rejection message and forwards it to subscribingcustomer 106 (message 10.2 in FIG. 5).

[0083] Otherwise, in step 314, warranty manager 230 _(IP) logs the termsof the requested warranty and transmits a proposed warranty totransaction coordinator 202 _(IP) (message 3.1 in FIGS. 4, 6). In step315, transaction coordinator 202 _(IP) digitally signs the proposedwarranty and forwards it to transaction coordinator 202 _(R) (message 4in FIGS. 4, 6). In step 316, transaction coordinator 202 _(R) forwardsthe proposed warranty message to warranty manager 230 _(R) (message 5 inFIGS. 4, 6).

[0084] In step 317, warranty manager 230 _(R) checks that the warrantyrequest is for a permitted amount (i.e., not greater than any maximumspecified by root entity 110 and not less than any minimum specified byroot entity 110). If the request is not for a permitted amount,processing proceeds to step 320, described below. In step 318, warrantymanager 230 _(R) checks that the warranty request is for a permittedclaim period (i.e., is for one of 7, 14, 30, 60, 90, or 180 days, in thepreferred embodiment described above). If the request is not for apermitted claim period, processing proceeds to step 320, describedbelow.

[0085] In step 319, warranty manager 230 _(R) retrieves from memory thewarranty cap utilization of issuing participant 102 and checks that therequested warranty amount will not cause issuing participant 102'sparticipant warranty cap to be exceeded, as well as any other warrantycaps that it has established (e.g., country warranty caps). If therequested warranty would cause any established cap to be exceeded, thenprocessing proceeds to step 320, described below.

[0086] If one or more of the above checks fail, then, in step 320,warranty manager 230 _(R) denies the requested warranty by transmittinga rejection message to transaction coordinator 202 _(R) (message 6.2 inFIG. 6). In step 321, transaction coordinator 202 _(R) digitally signsthe rejection message and forwards it to transaction coordinator 202_(IP) (message 7.2 in FIG. 6). In step 322, transaction coordinator 202_(IP) forwards the rejection message to warranty manager 230 _(IP)(message 8.2 in FIG. 6). In step 323, transaction coordinator 202 _(IP)formulates a rejection message and transmits it to subscribing customer106 (message 10.2 in FIG. 6).

[0087] Otherwise, in step 324, warranty manager 230 _(R) logs the termsof the proposed warranty and generates a unique warranty identification(ID) number for the warranty. In addition, warranty manager 230 _(R)updates the issuing participant's warranty cap utilization to reflectthe warranted amount. In step 325, warranty manager 230 _(R) generates awarranty confirmation that includes the warranty identification numberand transmits it to transaction coordinator 202 _(R) (message 6.1 inFIG. 4). In step 326, transaction coordinator 202 _(R) digitally signsthe warranty confirmation and forwards it to transaction coordinator 202_(IP) (message 7.1 in FIG. 4). In step 327, transaction coordinator 202_(IP) forwards the warranty confirmation to warranty manager 230 _(IP)(message 8.1 in FIG. 4). In step 328, warranty manager 230 _(IP) logsthe confirmation message and updates its warranty cap utilization toreflect the warranted amount. In step 329, warranty manager 230 _(IP)generates a warranty authorized and issued message comprising the termsof the warranty (message 9.1 in FIG. 4) and sends it to transactioncoordinator 202 _(IP). In step 330, transaction coordinator 202 _(IP)digitally signs the warranty authorized and issued message and forwardsit to subscribing customer 106 (message 10.1 in FIG. 4). In step 331,subscribing customer 106 appends the signed warranty authorized andissued message to its digital signature and returns the signedtransaction data to relying customer 108.

[0088] In step 332, relying customer 108 prepares an OCSP request tovalidate the certificate of the system component that signed thewarranty authorized and issued message (transaction coordinator 202_(IP) in this preferred embodiment). In step 333, relying customer 108transmits the request to relying participant 104 for validation. Thevalidation process may proceed in a manner analogous to that describedin co-pending U.S. application Ser. No. 09/657,605, filed Sep. 8, 2000,entitled System and Method for Providing Certificate Validation andOther Services, which is hereby incorporated by reference. In particularthe OCSP request may be transmitted to OCSP responder 204 _(IP) viatransaction coordinator 202 _(IP). OCSP responder 204 _(IP) prepares andsigns an OCSP response which is then returned to the relying participantvia transaction coordinator 202 _(IP). In a preferred embodiment, thisvalidation request may be bundled with a validation request forsubscribing customer 106's certificate and the two requests may bejointly processed.

[0089] In step 334, relying customer 108 receives the validationresponse from relying participant 104. If the validation is positive,relying customer 108 may be confident that the warranty is valid.

[0090] In a preferred embodiment, root entity 110 may establish as anoperating rule that a warranty issued in accordance with theabove-described preferred embodiment is effective as soon as it isissued and that no validation is required to render the warrantyenforceable. The operating rule may also preferably specify that if, atthe time the warranty was signed, an OCSP request for the certificate ofthe system component that signed the certificate (transactioncoordinator 202 _(IP) in this preferred embodiment, hereafter the“warranty issuer” or “issuer”) would have resulted in a negativeresponse, then the warranty is not enforceable.

[0091] As will be recognized, in this preferred embodiment, theenforceability of the warranty does not turn on whether or not relyingcustomer 108 actually requests validation of the issuer's certificate.Nevertheless, relying customer 108 may likely wish to validate theissuer's certificate before relying on the warranty because without suchvalidation, relying customer 108 cannot be certain that the warrantywill be enforceable.

[0092] In addition to benefitting the relying customer, this validationmay also facilitate business purposes important to system participants,including relying participant 104. In particular, since, as noted,relying customer 108 is typically a customer of relying participant 104,it may be desirable to provide relying customer 108 a strong motivationto continue to use services provided by relying participant 104, even incases where a warranty issued by issuing participant 102 (of whomrelying customer 108 is not necessarily a customer) is automaticallyenforceable without any action by relying participant 108. Thispreferred embodiment facilitates these business purposes because,although the issued warranty (if valid when signed) is enforceablewithout any action by relying customer 108, relying customer 108 willnevertheless likely choose to utilize its relying participant'svalidation service to validate the warranty issuer's certificate toensure that the warranty is enforceable.

[0093] In an alternative preferred embodiment that also facilitatesthese business purposes, root entity 110 may establish an operating rulethat a warranty issued in accordance with the above-described preferredembodiment does not go into effect until received by relying customer108. Proof of time of receipt may be established, for example, bytimestamping the received warranty with a third-party timestampingservice or by validating the warranty issuer's certificate andpreserving the timestamped OCSP response. The operating rule may alsospecify that, if between the time that the warranty was issued byissuing participant 102 and the time that the warranty was received byrelying participant 108, the warranty issuer's certificate becomesinvalid, then the warranty is unenforceable.

[0094] In this preferred embodiment as well, when a relying participant108 receives a warranty from a subscribing customer 106, it cannot becertain that the warranty will be enforceable against issuingparticipant 102 unless it confirms after receiving the warranty that thewarranty issuer's certificate remains valid. Accordingly, relyingparticipant 108 will likely wish to validate the warranty issuer'scertificate using its relying participant's validation service.

[0095] As will be recognized, in this preferred embodiment as well, thevalidity of the issued warranty does not turn on whether or not relyingcustomer requests validation of the warranty issuer's certificate. Inparticular, if the certificate is valid, the warranty will beenforceable even if the relying customer does not confirm its validstatus. Similarly, if the warranty issuer's certificate is invalid, thewarranty will not be enforceable even if the relying customer doesconfirm its invalid status. Thus, in the former case, the warranty isenforceable when received (although the relying customer may not knowthis for certain without validation) and does not require any action bythe relying customer to render it enforceable.

[0096] It should be recognized that although in the preferredembodiments described above, the warranty issuer is transactioncoordinator 202 _(IP), the warranty issuer may alternatively be someother component with signing capability maintained by issuingparticipant 102. For example, if warranty manager 230 _(IP) is providedwith digital signing capability (e.g., an HSM), then warranty manager230 _(IP) may itself sign all warranty messages created by issuingparticipant 102. Alternatively, another system component with signingcapability may be designated to sign all warranty messages created byissuing participant 102.

[0097] In addition, as noted above, although the preferred embodimentsdescribed above employs transaction coordinators at each participant102, 104 and at root entity 110, it should be noted that, in analternative embodiment, the system may be designed without some or allof these transaction coordinators. In this alternative embodiment,messages created, signed, or transmitted by, to, or via a transactioncoordinator in the following description, may instead be created,signed, or transmitted by, to, or via a substitute system componentadapted to comprise appropriate hardware and/or software to provide thedesired functionality. Thus, for example, the system may be designed sothat OCSP requests from a relying customer 108 are transmitted directlyto OCSP responder 204 _(IP) by the customer's relying participant 104and warranty messages to or from an issuing participant 102 aretransmitted directly to or from that participant's warranty manager 230_(IP).

Warranty Claim Procedure

[0098] In a preferred embodiment, relying customer 108, as a third-partybeneficiary, may bring a claim against an issuing participant 102 if awarranted fact in a warranty issued by the participant is incorrect, andthe relying customer suffers damage as a result of its reliance on thewarranted fact. A preferred embodiment of a process for filing andresolving warranty claims is now described in connection with FIG. 7 andFIG. 8.

[0099] Before commencing description of this preferred embodiment, abrief overview of the messages shown in FIG. 8 is presented. Preferredspecifications for each of these messages are described in more detailbelow. As shown in FIG. 8, the system utilizes the following messages inthe warranty-claim process:

[0100] (1) WCRequest: used by a relying customer 108 to file a claimagainst a warranty;

[0101] (2) WCNotification: used by a relying participant 104 to notifyan issuing participant 102 and root entity 110 of a filed claim;

[0102] (3) WCResponse: used by an issuing participant 102 to acknowledgereceipt of a filed claim;

[0103] (4) WCAck: used by root entity 110 to acknowledge receipt andprocessing of a filed claim.

[0104] As shown in FIG. 7, in step 701, relying customer 108 files awarranty claim with relying participant 104 by transmitting a WCRequestmessage to transaction coordinator 202 _(RP) of relying participant 104(message 1 in FIG. 8). Relying customer 108's claim must preferablyinclude the terms of the warranty (as specified in thewarranty-authorized-and-issued message), the date of the claim, and thewarranty claim amount.

[0105] In step 702, relying customer 108 provides relying participant104 with an affidavit certified by a duly authorized person on behalf ofrelying customer 108 that includes complete and detailed supportingdocumentation certifying the amount of damages claimed by relyingcustomer 108. Relying customer 108 also provides relying participant104, to the extent available, written documentation from subscribingcustomer 106 identifying the particular warranted fact that is allegedto be incorrect. For example, the written documentation from subscribingcustomer 106 may include a statement denying that it authorized aparticular digital signature or acknowledging that its certificate wasnot valid at the time of the transaction. In a preferred embodiment, thedocumentation submitted in this step must be submitted within 14 days ofthe warranty-claim filing.

[0106] In an alternative embodiment, relying customer 108 may submit itsclaim and supporting documentation directly to issuing participant 102.In this embodiment, the warranty-authorized-and-issued messagepreferably comprises information to aid relying customer 108 in filingits claim. This information may include a uniform resource locator (URL)that identifies a Web page that contains further claim-processinginformation and a mailing address for submitting supportingdocumentation. If relying customer 108 files its claim directly withissuing participant 102, then it preferably provides relying participant104 with copies of the documentation it files.

[0107] In step 703, relying participant 104 notifies issuing participant102 and root entity 110 of the filed claim by transmitting aWCNotification message to transaction coordinator 202 _(IP) of issuingparticipant 102 and transaction coordinator 202 _(R) of root entity 110(messages 2, 3 in FIG. 8). Transaction coordinators 202 _(IP), 202 _(R)forward the notifications to their respective warranty managers 230_(IP), 230 _(R) (messages 2.1, 3.1 in FIG. 8). In a preferredembodiment, these notifications must be made within twenty-four hours ofthe time relying participant 104 receives information regarding thefiled claim. The notification preferably includes the warranty ID forthe warranty that is the subject of the warranty and the warranty claimamount.

[0108] In step 704, warranty manager 230 _(IP) of issuing participant102 acknowledges receipt of the warranty claim by transmitting aWCResponse message to relying participant 104 via transactioncoordinator 202 _(IP) (messages 2.2, 2.3 in FIG. 8). In step 705,transaction coordinator 202 _(RP) of relying participant 104 forwardsthe message to relying customer 108 (message 4 in FIG. 8).

[0109] In step 706, warranty manager 230 _(R) of root entity 110 checksthe warranty-claim amount to confirm that it is not greater than thewarranted amount and that the date of the claim precedes the warrantyexpiration date. If both of these conditions are satisfied, thenwarranty manager 230 _(R) marks the warranty as “claimed” (step 707).Otherwise, the warranty claim is rejected (step 708). In step 709,warranty manager 230 _(R) releases the amount of the claim from issuingparticipant 102's warranty cap utilization. In a preferred embodiment,this release is performed 48 hours after a warranty is designated as“claimed.”

[0110] In a preferred embodiment, if a claim is filed for less than thefull amount of the warranty, then the unclaimed amount is treated asstill utilized under an issuing participant's warranty cap. For example,if issuing participant 102 issues a warranty for $500,000 and a claim isfiled for $200,000, then $200,000 is released from issuing participant102's warranty cap utilization, thus becoming available for writingadditional warranties. The remaining $300,000 continues be considered asutilized warranty cap, and is not released until the warranty expirationdate. If during the warranty claim period, claims for additional lossesare made against the remaining amount of the warranty, then the amountof those additional claims may at that time be released from issuingparticipant 102's warranty cap utilization.

[0111] In step 710, root entity places a hold on issuing participant102's collateral account for the claimed amount to cover the claim inthe event issuing participant 102 defaults. In step 711, warrantymanager 230 _(R) of root entity 110 acknowledges receipt and processingof the warranty claim by transmitting a WCAck message to relyingparticipant 104 via transaction coordinator 202 _(R) (messages 3.2, 3.3in FIG. 8).

[0112] In step 712, issuing participant 102 examines the claim and anysupporting documentation and determines whether it will pay the claim.If issuing participant 102 determines to pay the claim, then, in step713, issuing participant 102 transfers sufficient funds to cover theamount of the claim to relying participant 104 for the benefit ofrelying customer 108. Relying participant 104 preferably notifies rootentity 110 via a daily reporting procedure established by root entity110 once relying participant 104 has received these finds. Once rootentity 110 receives this notification, warranty manager 230 _(R)releases the hold on issuing participant 102's collateral account forthe amount of claim paid.

[0113] If issuing participant 102 determines not to pay the claim, then,in step 714, issuing participant 102 and relying customer 108 proceed todispute resolution to resolve the claim. An exemplary set of disputeresolution procedures is set forth in U.S. provisional applicationserial No. 60/153,443, filed Sep. 10, 1999, entitled System and Processfor Certification in Electronic Commerce, converted into co-pending U.S.patent application Ser. No. 09/657,623, filed Sep. 8, 2000, entitledSystem and Method for Providing Certificate-Related and Other Services,both of which are hereby incorporated by reference. Root entity 110preferably does not release collateral held to secure a disputedwarranty claim until the dispute is successfully resolved.

[0114] The claims procedure described above is further described in U.S.provisional application serial No. 60/153,443, filed Sep. 10, 1999,entitled System and Process for Certification in Electronic Commerce,converted into co-pending U.S. patent application Ser. No. 09/657,623,filed Sep. 8, 2000, entitled System and Method for ProvidingCertificate-Related and Other Services, both of which are herebyincorporated by reference.

Warranty Cap Calculation and Daily Processing

[0115] As noted, in a preferred embodiment, root entity 110 imposes awarranty cap on each issuing participant 102 that limits the warrantyvolume the participant may have outstanding at any point in time. Thesecaps are intended to control the aggregate level of operating riskexposure for individual participants and to control the overall risk inthe system.

[0116] In a preferred embodiment, warranty manager 230 _(R) of rootentity 110 is tasked with establishing each issuing participant'swarranty cap and adjusting the cap as appropriate. Warranty manager 230_(R) preferably takes into account a plurality of factors in calculatinga participant warranty cap, including the participant's total capital,operating loss factor, and credit rating. The credit rating ispreferably quantified as a credit discount factor so that it may beincorporated in the warranty-cap calculation, as described below. Inaddition, as noted below, a participant may raise its warranty cap bysubmitting credit-based collateral to a collateral agent to coverpotential warranty claims.

[0117] One preferred embodiment for calculating a participant warrantycap is:Participant  Warranty  Cap = (Total  Capital * (1/Operating  Loss  Factor) * Credit  Discount  Factor) + (Credit-Based  Collateral)

[0118] In a preferred embodiment, total capital represents the capitallevel of the legal entity under which a participant's certificationauthority operates (i.e., the entity that signs customer certificates).For example, if a participant operates its certification authority underan operating subsidiary, then the capital level of the subsidiary isused to determine the participant warranty cap. But if the issuingparticipant operates its certification authority as part of its mainfinancial services entity, then the total capital of that entity is usedto determine the participant warranty cap.

[0119] The operating loss factor preferably represents the historicaloperating loss of the issuing participant for operations within thepresent system. As will be recognized, when a participant firstcommences operation in the present system, it cannot immediately beassigned an actual operating loss factor, since there is no historicaldata from which to calculate it. Accordingly, in a preferred embodiment,all participants are initially assigned an estimated operating lossfactor of 0.6% derived in the chart below. Op Loss Factor as Measure %of Assets Source Bank Operating Loss 16-25 bps   First Manhattanestimates based on historical operating experience in processingbusinesses (1993-94) Mutual Fund Operating 40-50 bps   First Manhattanestimates; Mutual Losses Fund industry reports on reporting andprocessing anomalies (1993-94) Average 30 bps Conservative Add-on 2xEstimates Initial Operating Loss Factor 60 bps

[0120] Over time, the operating loss factor is preferably adjusted asactual operating loss data becomes available. In a preferred embodiment,a participant's operating loss factor is adjusted annually to reflectthe participant's actual operating loss for the most recent year.

[0121] As noted, each participant's credit rating is preferablytranslated into a credit discount factor. An exemplary set of creditratings and associated discount factors are set forth below: RatingDiscount Factor AAA (−⋄+) 1.0 AA (−⋄+) 1.0 A (−⋄+) 0.9 BBB+ 0.8 <BBB+not eligible without explicit collateralization of operations(credit-based collateral)

[0122] An exemplary calculation of a participant warranty cap isillustrated below. Component (Millions) Capital $2,000 Operating LossRate 0.60% Credit Rating (Discount Factor) AA (1.0) Total Warranty Cap$333,333

[0123] In a preferred embodiment, root entity 110 may initiallyestablish a participant warranty cap of $50,000,000 for each participantwhen the system is first established. The above warranty-cap formula maythen preferably be phased in as system entities gain operationalexperience.

[0124] Once a warranty cap is set for a particular participant, theparticipant's warranty volume may not exceed the cap. As noted, warrantymanager 230 _(R) preferably tracks each issuing participant's warrantycap utilization and checks each time a warranty is proposed to ensurethat the participant's cap will not be exceeded. In addition, warrantymanager 230 _(R) may check an issuing participant's warranty caputilization against its participant warranty cap at predeterminedintervals, such as daily. If a participant exceeds its warranty cap,then root entity 110 may take reasonable steps to address the situation,including but not limited to, fining the participant or suspending itscertificate.

[0125] In a preferred embodiment, warranty manager 230 _(R) is adaptedto report to participants their warranty cap utilization and outstandingwarranty claims on a regular basis. The reporting frequency maypreferably be a function of the percentage of a participant's warrantycap that is currently being utilized. One preferred embodiment of areporting schedule is as follows: Position at beginning of Period (i.e.,Daily) Reporting Frequency Less than 80% of Warranty Daily Cap 80-90% ofCap 4 hours Greater than 90% of Cap Real Time

Collateral Requirement Calculation and Daily Processing

[0126] As noted, in a preferred embodiment, root entity 110 imposescollateral requirements on each issuing participant 102 that may be usedto pay claims for damages filed by relying customers if the issuingparticipant is unable or unwilling to satisfy such claims. Although theamount of required collateral need not be adequate to ensure fullcoverage of all outstanding warranties, the collateral amount ispreferably adequate to materially increase the probability of a relyingcustomer's recovery on a warranty claim in the event that an issuingparticipant is unable or unwilling to honor such a claim.

[0127] In a preferred embodiment, the total collateral amount posted byan issuing participant 102 is made up of two components:performance-based collateral and credit-based collateral. In a preferredembodiment, the performance-based collateral requirement for an issuingparticipant 102 may be calculated as follows:Performance-Based  Collateral  Requirement=  [Warranty  Volume  Outstanding * Operating  Loss  Factor] +   [Aggregate  Amount  of  Outstanding  Unpaid  Warranty  Claims]

[0128] All system participants are preferably required to postperformance-based collateral.

[0129] Credit-based collateral is collateral that an issuing participantchooses to post in order to increase its warranty cap. If a participantelects to post credit-based collateral, then it is preferably requiredto maintain the credit-based collateral until it changes its electionand its warranty cap no longer includes the credit-based collateral.

[0130] An exemplary calculation of the required collateral amount for anissuing participant 102 is illustrated below. For purposes of thisexample, it is assumed that issuing participant 102 has $500 million inissued warranties, an operating loss factor of 0.6%, and outstandingwarranty claims of $200,000. As such, issuing participant 102 mustmaintain in this preferred embodiment a minimum of $3.2 million inperformance-based collateral for the benefit of relying customers in theevent of default on a warranty claim. As further assumed in the examplebelow, if issuing participant 102 wishes to post an additional $2million in credit-based collateral to increase its warranty cap, thenits total required collateral amount would be $5.2 million. Component$(millions) (a) Outstanding Claims (100%) $.20 (b) Warranties Issued$500 (c) Operating Loss Rate 0.60% (d) Projected Claims Rate (b*c) $3.00Performance-Based Collateral $3.20 (a + d) Credit-Based Collateral $2.00Total Required Collateral $5.20

[0131] In a preferred embodiment, root entity 110 designates the typesof collateral (called eligible collateral) that may be posted byparticipants in satisfaction of the collateral requirements describedabove. In one preferred embodiment, the only eligible collateral areU.S. dollars and direct obligations of the U.S. government (e.g., U.S.treasury securities). In other preferred embodiments, root entity 110may establish additional types of eligible collateral.

[0132] In a preferred embodiment, each issuing participant selects itsown collateral agent for purposes of administering collateral that itmust post. Each issuing participant preferably establishes a collateralaccount with its collateral agent specifically for the collateral postedin satisfaction of these collateral requirements. Preferably,credit-based collateral is held in a separate account thanperformance-based collateral.

[0133] In a preferred embodiment, the collateral agent is subject to acontractual obligation under which it may be directed to pay a warrantyclaim from a participant's collateral account if that participantrefuses to pay the claim. Payment may preferably be directed from bothcredit-based collateral and performance-based collateral to satisfy aclaim.

[0134] In a preferred embodiment, root entity 110 updates each issuingparticipant's collateral requirements and monitors the participant forcompliance with those requirements on a regular basis, preferably daily.A preferred updating and monitoring process is now described inconnection with FIG. 9.

[0135] As shown in FIG. 9, in step 901, the collateral agent calculatesa value for the collateral posted with it by issuing participant 102. Inperforming this calculation, the collateral agent preferably usesreliable pricing sources to obtain closing market prices of eachsecurity included in the collateral. In a preferred embodiment, thecollateral value is calculated as the sum of the market values of eachsecurity included in the collateral multiplied by a haircut for thatsecurity preferably determined by root entity 110. Any collateral thatis not eligible collateral is preferably assigned a market value of zeroin this valuation.

[0136] In step 902, the collateral agent transmits the calculatedcollateral value to root entity 110. In step 903, root entity 110calculates the issuing participant's required collateral amount.

[0137] In step 904, root entity 110 calculates a delivery amount orreturn amount for the issuing participant and notifies the issuingparticipant of its required collateral amount and this delivery amountor return amount. A delivery amount is the amount, if any, by which therequired collateral amount exceeds the collateral value. A return amountis the amount, if any, by which the collateral value exceeds therequired collateral amount.

[0138] If root entity 110 notifies the participant of a delivery amount,then, in step 905, the issuing participant must deliver eligiblecollateral with a collateral value at least equal to that deliveryamount to its collateral agent. Failure to satisfy this requirementwithin one business day is grounds for suspension of the participant.Otherwise, if root entity 110 notifies the participant of a returnamount, then, in step 906, the participant may elect to request thereturn of collateral with a collateral value no greater than the returnamount from its collateral agent.

Warranty Manager Implementation

[0139] In a preferred embodiment, warranty manager 230 is implemented asa database application. If desired, warranty manager 230 may be designedas a true message processing application with a messaging queue 235 andother message processing capabilities as shown, for example in FIG. 10.Alternatively, warranty manager 230 may be designed as a function callprocessing application with no messaging support as shown in FIG. 11.

[0140] In a preferred embodiment, warranty manager 230 comprises awarranty manager API 240. API 240 is preferably established by rootentity 110 and adapted to process all warranty messages exchangedbetween a warranty manager 230 and a transaction coordinator 202.

[0141] In a preferred embodiment, API 240 is adapted to handleextensible markup language (XML) warranty messages, although otherwarranty message formats may be supported. API 240 is preferably adaptedto enable warranty manager 230 to accept an XML warranty message, parsethe contents of the message, and generate a new XML message as output.In order to simplify message processing, warranty manager API 240 ispreferably adapted to use a different function to process each of thewarranty messages described below.

[0142] In a preferred embodiment, API 240 is implemented in C++.Alternatively, if implemented in Java, API 240 preferably follows thesame class and method structure as the C++ implementation describedbelow.

[0143] In a preferred embodiment, API 240 is implemented as a singleinheritance C++ class derived from a generic CObject class withappropriate public methods. All API functions return a boolean value ofTRUE if successful, otherwise they return FALSE.

[0144] In a preferred embodiment, API 240 is adapted to accept aparameter that sets the environment in which warranty manager 230operates. The operating environment of warranty manager 230 preferablycorresponds to the entity at which warranty manager 230 is implemented.Thus, for example, when initializing or communicating with warrantymanager 230 _(R) at root entity 110, this parameter is preferably set toa first value and when initializing or communicating with a warrantymanager 230 _(IP) at an issuing participant 102, this parameter ispreferably set to a second value.

[0145] A preferred embodiment of API 240 is as follows: typedef structxmlmsg { char* buffer; // buffer is sufficiently large to hold entiremessage }; class CWarrantyManager : public CObject { public:CWarrantyManager (char startupType) BOOL WMVersion (unsigned short*vmajor, unsigned short *vminor, char *IPorIR); BOOL WMAlive(void); BOOLWMLastError(unsigned errCode, char* errTxt); BOOL IPRequest (xmlmsg *m2,xmlmsg *m3); BOOL IRRequest (xmlmsg *m5,xmlmsg *m6); BOOLIPValidationReport (xmlmsg ipvm); BOOL IRValidationReport (xmlmsg irvm);BOOL IPWC(xmlmsg ipwcNotify, xmlmsg ipwcResp); BOOL RTWC(xmlmsgrtwcNotify, xmlmsg rtwcAck); };

CWarrantyManager::CWarrantyManager

[0146] Constructor. Preferably there is only one instance of warrantymanager 230 running CWarrantyManager( char startup Type // Sets theenvironment in which this warranty manager instance runs );

Parameters

[0147] startupType character indicating “IP” for issuing participant 102or “IR” for root entity 110.

CWarrantyManager::WMVersion

[0148] Returns the version of the warranty manager code that isinstantiated in this instance of warranty manager 230. BOOL WMVersion(unsigned short *vmajor, // major version number unsigned short *vminor,// minor version number char *PorIR // startup type character );

Parameters

[0149] major major version number

[0150] vminor minor version number

[0151] IP or IR character indicating “IP” for issuing participant 102 or“IR” for root entity 110.

CWarrantyManager::WMAlive

[0152] Returns boolean TRUE if this instance of warranty manager 230 isresponding.

[0153] BOOL WMAlive();

Parameters

[0154] none

CWarrantyManager::WMLastError

[0155] Returns the last known error code of warranty manager 230. Theseerror codes are implementor specific. BOOL WMLastError( unsigned*errCode, // numeric error code char *errTxt, // pointer to text buffer);

Parameters

[0156] errCode pointer to buffer for receiving numeric error code erTxtpointer to a buffer that will hold the returned error text. Returnedtext not to exceed 1024 bytes.

CWarrantyManager::IPRequest

[0157] Posts a warranty request message to warranty manager 230 _(IP).This call returns FALSE if the CWarrantyManager startup type is “IR.”BOOL IPRequest( xmlmsg *m2, // pointer to input message xmlmsg *m3, //pointer to output message );

Parameters

[0158] m2 Pointer to xmlmsg structure holding the input message m3Pointer to xmlmsg

CWarrantyManager::IRRequest

[0159] Posts a proposed warranty request message to warranty manager 230_(R). This call returns FALSE if the CWarrantyManager startup type is“IP.” BOOL IRRequest( xmlmsg *m5, // pointer to input message xmlmsg*m6, // pointer to output message );

Parameters

[0160] m5 Pointer to xmlmsg structure holding the input message m6Pointer to xmlmsg structure to receive the output message

CWarrantyManager::IPValidationReport

[0161] Posts an issuing participant identity validation reportingmessage to warranty manager 230 _(IP). This call should return FALSE ifthe CWarrantyManager startup type is “IR.” BOOL IPValidationReport(xmlmsg *ipvm, // pointer to input message );

Parameters

[0162] ipvm Pointer to xmlmsg structure holding the input message

CWarrantyManager::IRValidationReport

[0163] Posts a root entity identify validation reporting message towarranty manager 230 _(R). This call returns FALSE if theCWarrantyManager startup type is “IP.” BOOL IRValidationReport( xmlmsg*irvm, // pointer to inputmessage );

Parameters

[0164] irvm Pointer to xmlmsg structure holding the input message

CWarrantyManager::IPWC

[0165] Posts a warranty claims message to warranty manager 230 _(IP).This call returns FALSE if the CWarranty Manager startup type is “IR.”BOOL IPWC( xmlmsg *ipwcNotify, // pointer to input message xmlmsg*ipwcResp, // pointer to output message );

CWarrantyManager::RTWC

[0166] Posts a warranty claims message to warranty manager 230 _(R).This call returns FALSE if the CWarrantyManager startup type is “IP.”BOOL RTWC( xmlmsg *rtwcNotify, // pointer to input message xmlmsg*rtwcAck, // pointer to output message );

Warranty Messages Specification

[0167] As noted above, in a preferred embodiment, the following messagesare used in the warranty-issuance process: (1) a warranty requestmessage (Wrequest), (2) a warranty proposed message (Wproposed), (3) awarranty confirmation message (Wconfirmation), (4) a warranty authorizedand issued message (Wauthorizedandissued), and (5) a warranty rejectmessage (WReject).

[0168] In addition, the following messages are used in thewarranty-claim process: (1) a warranty claim request message(WCRequest), (2) a warranty claim notification message (WCNotification),(3) a warranty claim response message (WCResponse), and (4) a warrantyclaim acknowledgment message (WCAck).

[0169] The following messages are used to report the daily number ofcertificate validations performed by an issuing participant: an issuingparticipant identity validation reporting message(WIPValidationReporting) and a root entity identity validation reportingmessage (WIRValidationReporting).

[0170] The following message is used to report errors in the warrantyprocess: a warranty error message (Werror).

[0171] The following message is used to report a warranted transactionthat has been canceled: a warranty canceled message (Wcanceled).

[0172] In a preferred embodiment, all warranty messages are definedaccording to a document type definition (DTD). Root entity 110preferably establishes a common DTD for system entities. The DTDprovides the formal description of all valid XML warranty messages usedin the system. Hence, system entities may use the DTD to verify that themessages they transmit and receive are valid. A preferred embodiment ofa suitable DTD is described below.

[0173] In a preferred embodiment, a complete XML warranty messagecomprises an XML declaration, a DTD reference, an XML namespaceattribute (xmlns), and a set of data elements. An exemplary XMLdeclaration is as follows:

[0174] <?xml version=“1.0” encoding=“UTF-8”?>

[0175] <!--Root Entity Warranty Manager Version 1.0-->

[0176] <!--Warranty Manager DTD ->

[0177] An exemplary DTD reference is as follows:

[0178] <!DOCTYPE WRequest PUBLIC

[0179] “//Root Entity//WARRANTY MANAGER DTD//EN” “Warranty.dtd”>

[0180] In a preferred embodiment, an xmlns attribute is used to identifythe top-level entity in the DTD, i.e., root entity 110. This is done toprevent conflicts between names used in the warranty-message DTD andother DTDs. The value of the xmlns attribute is preferably fixed andmay, for example, be set to “http://www.nameofrootentity.com”. Anexemplary warranty-message DTD definition of the xmlns attribute is asfollows: <!ATTLIST WarrantyRequest xmlns CDATA #FIXED “http://www.rootentity.com” >

[0181] A preferred implementation of the data elements included in theabove-described XML messages are now described.

[0182]FIG. 12 illustrates the data elements used to construct warrantymessages in a preferred embodiment of the present system. FIG. 13provides descriptions and restrictions for each data element in thispreferred embodiment.

[0183] A warranty request message preferably includes the following dataelements:

[0184] Warranty Request Message Code (indicating that the message is awarranty request)

[0185] Warranty Amount

[0186] Warranty Currency Type

[0187] Warranty Claim Period

[0188] Relying Customer Name and Identifier

[0189] Subscribing Customer Name and Identifier

[0190] Subscribing Customer Transaction ID

[0191] Relying Customer Transaction ID

[0192] Timestamp (with acceptable variance of ±/−5 minutes from rootentity 110 time)

[0193] In a preferred embodiment, the warranty request message may notinclude any other information, such as the contents of the underlyingtransaction. A preferred XML implementation for the data elements ofthis message is: <WRequest>  <WAmount Currency=“USD”>100000<WAmount> <WClaimPeriod Days=“14” />  <RCNameAndId>  <X509IssuerSerial><X509IssuerName>CN=L1B1 Certificate Authority, OU=Root Entity, O=RootEntity, C=US</X509IssuerName><X509SerialNumber>979827336</X509SerialNumber>  </X509IssuerSerial> </RCNameAndId>  <SCNameAndId > <X509IssuerSerial><X509IssuerName>CN=L1B2 Certificate Authority, OU=Root Entity, O=RootEntity, C=US</X509IssuerName><X509SerialNumber>918827438</X509SerialNumber>  </X509IssuerSerial> </SCNameAndId >  <SCTransactionId Id=“12345631232131678387589” /> <RCTransactionId Id=“65432855775334990885891” /> <WRTimestampDateTime=“20000812163000Z” /> </WRequest>

[0194] A warranty proposed message preferably includes the followingdata elements:

[0195] Warranty Proposed Message Code (indicating that the message is aproposed warranty)

[0196] Warranty Amount

[0197] Warranty Currency Type

[0198] Warranty Claim Period

[0199] Subscribing Customer Transaction ID

[0200] Relying Customer Transaction ID

[0201] Timestamp

[0202] Issuing Participant Name and Identifier

[0203] Warranty Alternate Currency Amount

[0204] Warranty Alternate Currency Type

[0205] A preferred XML implementation for the data elements of thismessage is: <WProposed>  <WAmount Currency=“USD”>100000</WAmount> <WClaimPeriod Days=“14”/>  <SCTransactionIdId=“12345631232131678387589” />  <RCTransactionIdId=“65432855775334990885891” />  <WRTimestampDateTime=“20000812163000Z”/>  <IPNameAndId> <X509IssuerSerial><X509IssuerName>CN=ROOT Certificate Authority, OU=Root Entity, O=RootEntity, C=US</X509IssuerName><X509SerialNumber>916627188</X509SerialNumber> </X509IssuerSerial> </IPNameAndId>  <WAlternateAmount Currency=“GBP”>140000 </WAlternateAmount> <WProposed>

[0206] A warranty confirmation message preferably includes the followingdata elements:

[0207] Warranty Confirmation Message Code (indicating that the messageis a confirmation of a proposed warranty)

[0208] Warranty ID

[0209] Warranty Amount

[0210] Warranty Currency Type

[0211] Warranty Claim Period

[0212] Subscribing Customer Transaction ID

[0213] Relying Customer Transaction ID

[0214] Timestamp

[0215] Issuing Participant Name and Identifier

[0216] Warranty Alternate Currency Amount

[0217] Warranty Alternate Currency Type

[0218] Warranty Expiration Date and Time

[0219] A preferred XML implementation for the data elements of thismessage is: <WConfirmation>  <WarrantyId Id=“9876540123XXXX” /> <WAmount Currency=“USD”>100000</WAmount>  <WClaimPeriod Days=“14”/> <SCTransactionId Id=“12345631232131678387589” />  <RCTransactionIdId=“65432855775334990885891” />  <WRTimestampDateTime=“20000812163030Z”/>  <IPNameAndId> <X509IssuerSerial><X509IssuerName>CN=ROOT Certificate Authority, OU=Root Entity, 0=RootEntity, C=US</X509IssuerName><X509SerialNumber>916627188</X509SerialNumber> </X509IssuerSerial> </IPNameAndId>  <WAlternateAmountCurrency=“GBP”>140000 <WAlternateAmount>  <ExpiryDateDateTime=“20002212090000Z”/></WConfirmation >

[0220] A warranty authorized and issued message preferably includes thefollowing data elements:

[0221] Warranty Authorized and Issued Message Code (indicating that themessage indicates warranty approval and issuance)

[0222] Warranty ID

[0223] Warranty Amount

[0224] Warranty Currency Type

[0225] Warranty Claim Period

[0226] Relying Customer Name and Identifier

[0227] Subscribing Customer Name and Identifier

[0228] Subscribing Customer Transaction ID

[0229] Relying Customer Transaction ID

[0230] Timestamp

[0231] Issuing Participant Name and Identifier

[0232] Warranty Alternate Currency Amount

[0233] Warranty Alternate Currency Type

[0234] Warranty Expiration Date and Time

[0235] A preferred XML implementation for the data elements of thismessage is: <WAuthorizedAndIssued >  <WarrantyId Id=“9876540123XXXX” /> <WAmount Currency=“USD”>100000</WAmount>  <WClaimPeriod Days=“14”/> <RCNameAndId> <X509IssuerSerial> <X509IssuerName>CN=L1B1 CertificateAuthority, OU=Root Entity, O=Root Entity, C=US</X509IssuerName><X509SerialNumber>979827336</X509SerialNumber> </X509IssuerSerial> </RCNameAndId>  <SCNameAndId > <X509IssuerSerial><X509IssuerName>CN=L1B2 Certificate Authority, OU-Root Entity, O=RootEntity, C=US</X509IssuerName><X509SerialNumber>918827438</X509SerialNumber> </X509IssuerSerial> </SCNameAndId >  <SCTransactionId Id=“12345631232131678387589” /> <RCTransactionId Id=“65432855775334990885891” />  <WRTimestampDateTime=“20000812163000Z”/>  <IPNameAndId> <X509IssuerSerial><X509IssuerName>CN=ROOT Certificate Authority, OU=Root Entity, O=RootEntity, C=US</X509IssuerName><X509SerialNumber>916627188</X509SerialNumber> </X509IssuerSerial> </IPNameAndId>  <WAlternateAmountCurrency=“GBP”>140000 </WAlternateAmount>  <ExpiryDate DateTime-“20002212090000Z”/></WAuthorizedAndIssued>

[0236] A warranty reject message preferably includes the following dataelements:

[0237] Warranty Rejected Message Code (indicating that the message is awarranty rejection)

[0238] Reason Code and Text

[0239] Subscribing Customer Transaction ID

[0240] Relying Customer Transaction ID

[0241] Timestamp

[0242] A preferred set of reason texts for this message when the messageis generated by issuing participant 102 is:

[0243] Please contact your relationship manager.

[0244] Subscribing customer 106 exceeds warranty cap.

[0245] Issuing participant 102 is unable to issue a warranty.

[0246] Issuing participant 102 will review warranty request. Pleaseresubmit after 24 hours.

[0247] Issuing participant 102 will review warranty request. Pleaseresubmit after 48 hours.

[0248] Issuing participant 102 will review warranty request. Pleaseresubmit after 72 hours.

[0249] Subscribing customer 106 not known/not a customer of the issuingparticipant 102.

[0250] Subscribing customer 106 certificate revoked or suspended.

[0251] A preferred set of reason texts for this message when the messageis generated by root entity 110 is:

[0252] Issuing participant exceeds warranty cap.

[0253] Root entity is unable to verify issuing participant status.

[0254] A preferred XML implementation for the data elements of thismessage is: <WReject Code=“200” Reason=“Issuing Participant exceedswarranty cap”> <SCTransactionId Id=“12345631232131678387589” /><RCTransactionId Id=“65432855775334990885891” /> <WRTimestampDateTime=“20000812163050Z”/> </WReject>

[0255]FIG. 14 illustrates the data elements used to construct warrantyclaim messages in a preferred embodiment of the present system.

[0256] A warranty claim request message preferably includes thefollowing data elements:

[0257] Warranty Claim Request Message Code (indicating that the messageis a warranty claim request)

[0258] Warranty Authorized and Issued Message Received from SubscribingCustomer

[0259] Claim Amount

[0260] Claim Currency Type

[0261] Timestamp

[0262] A preferred XML implementation for the data elements of thismessage is: <WCRequest> <WAuthorizedAndIssued> <WarrantyIdId=“9876540123XXXX” /> <WAmount Currency=“USD”>100000</WAmount><WClaimPeriod Days=“14”/> <RCNameAndId> <X509IssuerSerial><X509IssuerName>CN=L1B1 Certificate Authority, OU=Root Entity, O=RootEntity, C=US</X509IssuerName><X509SerialNumber>979827336</X509SerialNumber> </X509IssuerSerial></RCNameAndId> <SCNameAndId > <X509IssuerSerial> <X509IssuerName>CN=L1B2Certificate Authority, OU=Root Entity, O=Root Entity,C=US</X509IssuerName> <X509SerialNumber>918827438</X509SerialNumber></X509IssuerSerial> </SCNameAndId > <SCTransactionIdId=“12345631232131678387589” /> <RCTransactionIdId=“65432855775334990885891” /> <WRTimestampDateTime=“20000812163000Z”/> <IPNameAndId> <X509IssuerSerial><X509IssuerName>CN=ROOT Certificate Authority, OU=Root Entity, O=RootEntity, C=US</X509IssuerName><X509SerialNumber>916627188</X509SerialNumber> </X509IssuerSerial></IPNameAndId> <WAlternateAmountCurrency=“GBP”>140000</WAlternateAmount> <ExpiryDate DateTime=“20002212090000Z”/></WAuthorizedAndIssued> <WClaimAmountCurrency=“USD”>100000</WClaimAmount> <WRTimestampDateTime=“20000820163000Z”/> </WCRequest>

[0263] A warranty claim notification message preferably includes thefollowing data elements:

[0264] Warranty Claim Notification Message Code (indicating that themessage is a warranty claim notification)

[0265] Warranty ID

[0266] Warranty Claim Number ID

[0267] Claim Amount

[0268] Claim Currency Type

[0269] Timestamp

[0270] A preferred XML implementation for the data elements of thismessage is: <WCNotification> <WarrantyId Id=“9876540123XXXX” /><WClaimNo Id=“123456” /> <WClaimAmountCurrency=“USD”>100000<WClaimAmount> <WRTimestampDateTime=“20000820163001Z”/> </WCNotification>

[0271] A warranty claim response message preferably includes thefollowing data elements:

[0272] Warranty Claim Response Message Code (indicating that the messageis a warranty claim response)

[0273] Warranty ID

[0274] Warranty Claim Number ID

[0275] Claim Amount

[0276] Claim Currency Type

[0277] Timestamp

[0278] A preferred XML implementation for the data elements of thismessage is: <WCResponse> <WarrantyId Id=“9876540123XXXX” /> <WClaimNoId=“123456” /> <WClaimAmount Currency=“USD”>100000</WClaimAmount><WRTimestamp DateTime=“20000820163001Z”/> </WCResponse>

[0279] A warranty claim acknowledgment message preferably includes thefollowing data elements:

[0280] Warranty Claim Acknowledgment Message Code (indicating that themessage is a warranty claim acknowledgment)

[0281] Warranty ID

[0282] Warranty Claim Number ID

[0283] Claim Amount

[0284] Claim Currency Type

[0285] Timestamp

[0286] A preferred XML implementation for the data elements of thismessage is: <WCAck> <WarrantyId Id=“9876540123XXXX” /> <WClaimNoId=“123456” /> <WClaimAmount Currency=“USD”>100000<WClaimAmount><WRTimestamp DateTime=“20000820163001Z”/> <WCAck>

[0287]FIG. 15 shows a preferred list of data elements, and correspondingdescriptions and restrictions, used to construct validation reportingmessages that may be used to report the number of validations performedby a participant in a preferred embodiment of the present system.

[0288] An issuing participant validation reporting message preferablyincludes the following data elements:

[0289] An Issuing Participant Validation Reporting Message Code(indicating that the message is an issuing participant validationreporting message)

[0290] Validation Count

[0291] Validation Period

[0292] Timestamp

[0293] A preferred XML implementation for the data elements of thismessage: <WIPValidationReporting > <IPValidation Count=“125”/><PeriodFrom DateTime=“20000912163050Z”/> <PeriodToDateTime=“20001012163050Z”/> <WRTimestamp DateTime=“20001012163050Z”/></WIPValidationReporting >

[0294] A root validation reporting message preferably includes thefollowing data elements:

[0295] A Root Entity Validation Reporting Message Code (indicating thatthe message is a root entity validation reporting message)

[0296] Issuing Participant Name and Identifier

[0297] Validation Count

[0298] Validation Period

[0299] Timestamp

[0300] A preferred XML implementation for the data elements of thismessage is: <WIRValidationReporting> <IPNameAndId Id=“987654”Name=“IP1”/> <IPValidation Count=“125”/> <PeriodFromDateTime=“20000912163050Z”/> <PeriodTo DateTime=“20001012163050Z”/><WRTimestamp DateTime=“20001012163050Z”/> </WIRValidationReportmg>

[0301] If an error occurs during the warranty process, then a warrantyerror message is generated. A warranty error message preferably includesthe following data elements:

[0302] An Error Message Code (indicating that the message reports anerror in the warranty process)

[0303] Error Code and Description

[0304] Subscribing Customer Transaction ID

[0305] Relying Customer Transaction ID

[0306] Timestamp

[0307] A preferred XML implementation for the data elements of thismessage is: <WError Code=“901” Description=“Warranty Amount must begreater than 500 USD”> <SCTransactionId Id=“12345631232131678387589” /><RCTransactionId Id=“65432855775334990885891” /> <WRTimestampDateTime=“20000812163050Z”/> </Werror>

[0308] If the transaction between subscribing customer 106 and relyingcustomer 108 does not take place, then a warranty canceled message isgenerated by the entity that requested the warranty and transmitted tothe warranty issuer. Upon receipt of the warranty canceled message, thewarranty amount is preferably released from both the requestor's and theissuer's warranty cap utilization. A warranty canceled messagepreferably includes the following data elements:

[0309] A Warranty Canceled Message Code (indicating that the entity thatrequested the warranty wishes to cancel the warranty)

[0310] Date and Time Canceled

[0311] Warranty ID

[0312] A preferred XML implementation for the data elements of thismessage is: <Wcanceled> <DateTime Canceled=“20002120900002”/><WarrantyId Id=987640123XXXX”> </Wcanceled>

[0313] A preferred embodiment of a DTD for warranty messages is asfollows: <?xml version=“1.0” encoding=“UTF-8”?> <!-- Root EntityWarranty Manager Version 1.0 --> <!-- Warranty Manager DTD --> <!--Warranty=WRequest|WProposed|WConfirmation|WAuthorizedAndIssued|WReject|WIRValidationReporting|WIPValidationReporting|Werror --> <!ENTITY %XMLDSIG.dtd PUBLIC “-//W3C//XMLDSIG//EN” “http://www.rootentity.com/TC/2.0/XMLDSIG.dtd”> %XMLDSIG.dtd; <!ELEMENT WRequest(WAmount,WClaimPeriod,RCNameAndId,SCNameAndId,SCTransactionId,RCTransactionId,WRTimestamp)> <!ELEMENT WAmount (#PCDATA)> <!ATTLIST WAmountCurrency CDATA #REQUIRED > <!ELEMENT WClaimPeriod EMPTY> <!ATTLISTWClaimPeriod Days CDATA #REQUIRED > <!ELEMENT RCTransactionId EMPTY><!ATTLIST RCTransactionId Id CDATA #REQUIRED > <!ELEMENT SCTransactionIdEMPTY> <!ATTLIST SCTransactionId Id CDATA #REQUIRED > <!ELEMENTRCNameAndId (X509IssuerSerial)> <!ELEMENT SCNameAndId(X509IssuerSerial)> <!ELEMENT IPNameAndId (X509IssuerSerial)> <!ELEMENTWRTimestamp EMPTY> <!ATTLIST WRTimestamp DateTime CDATA #REQUIRED ><!ELEMENT WProposed(WAmount,WClaimPeriod,SCTransactionId,RCTransactionId,WRTimestamp,IPNameAndId,WAalternateAmount?)> <!ELEMENT WAlternateAmount (#PCDATA)> <!ATTLISTWAlternateAmount Currency CDATA #REQUIRED > <!ELEMENT WConfirmation(WarrantyId,WAmount,WClaimPeriod,SCTransactionId,RCTransactionId,WRTimestamp,I PNameAndId,WAlternateAmount?,ExpiryDate)> <!ELEMENTWarrantyId EMPTY> <!ATTLIST WarrantyId Id CDATA #REQUIRED > <!ELEMENTExpiryDate EMPTY> <!ATTLIST ExpiryDate DateTime CDATA #REQUIRED ><!ELEMENT WAuthorizedAndIssued(WarrantyId,WAmount,WClaimPeriod,RCNameAndId,SCNameAndId,SCTransactionId,RCTransactionId,WRTimestamp,IPNameAndId,WAlternateAmount?,ExpiryDate)><!ELEMENT WReject (SCTransactionId,RCTransactionId,WRTimestamp)><!ATTLIST WReject Code CDATA #REQUIRED Reason CDATA #REQUIRED ><!ELEMENT WIRValidationReporting (IPNameAndId, IPValidation, PeriodFrom,PeriodTo, WRTimestamp)> <!ELEMENT WIRAck (IPNameAndId, IPValidation,PeriodFrom, PeriodTo, WRTimestamp)> <!ELEMENT IPValidation EMPTY><!ATTLIST IPValidation Count CDATA #REQUTRED > <!ELEMENT PeriodFromEMPTY> <!ATTLIST PeriodFrom DateTime CDATA #REQUIRED > <!ELEMENTPeriodTo EMPTY> <!ATTLIST PeriodTo DateTime CDATA #REQUIRED > <!ELEMENTWIPValidationReporting (IPValidation, PeriodFrom, PeriodTo,WRTimestamp)> <!ELEMENT WError(SCTransactionId?,RCTransactionId?,WRTimestamp)> <!ATTLIST WError CodeCDATA #REQUIRED Description CDATA #REQUIRED > <!ELEMENT WCRequest(WAuthorizedAndIssued, WClaimAmount, WRTimestamp)> <!ELEMENT WClaimNoEMPTY> <!ATTLIST WClaimNo Id CDATA #REQUIRED > <!ELEMENT WClaimAmount(#PCDATA)> <!ATTLIST WClaimAmount Currency CDATA #REQUIRED > <!ELEMENTWCNotification (WarrantyId, WClaimNo, WClaimAmount, WRTimestamp)><!ELEMENT WCAck (WarrantyId, WClaimNo, WClaimAmount, WRTimestamp)><!ELEMENT WCResponse (WarrantyId, WClaimNo, WClaimAmount, WRTimestamp)>

[0314] An alternative embodiment for implementing the theabove-described messages and DTD is described in U.S. provisionalapplication serial No. 60/ 259,796, filed Jan. 4, 2001, entitledWarranty Manager Application Programming Interface, Warranty MessagingSpecification, and Warranty Manager Functional Requirements, which ishereby incorporated by reference.

[0315] While the invention has been described in conjunction withspecific embodiments, it is evident that numerous alternatives,modifications, and variations will be apparent to those skilled in theart in light of the foregoing description.

1. A method for providing warranties that warrant one or more factsassociated with a digitally-signed electronic message, comprising:assigning a warranty cap to an entity that issues digital certificates;tracking a warranty volume for the entity; receiving a request for awarranty from a subscriber to whom the entity issued a digitalcertificate, the request for a warranty specifying a warranted amountand claim period; evaluating the request for a warranty to ensure thatthe warranted amount will not cause the entity's warranty volume toexceed the entity's warranty cap; transmitting a message that confirmsissuance of the requested warranty, the message being digitally signedby a component maintained by the entity, the warranty comprising acontract between the entity and the subscriber, a relying party being athird-party beneficiary to the contract; receiving a validation requestfrom the relying party, the validation request requesting validation ofa digital certificate for the component that signed the messageconfirming issuance of the requested warranty; transmitting a validationresponse to the relying party.